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PARTITION MANIPULATION 
ARCHITECTURE SUPPORTING MULTIPLE 
FILE SYSTEMS 

RELATED APPLICATIONS 

The present application is a continuation-in-part of com- 
monly owned U.S. patent application Ser. No. 08/393,805, 
U.S. Pat. No. 5,675,769 filed Feb. 23, 1995, Ser. No. 
08/554,828, filed Nov, 7, 1995 and Ser. No. 60/026,585, 
filed Sep. 19, 1996 (collectively "the parent applications"). 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. The copyright owner does not hereby 
waive any of its rights to have this patent document main- 
tained in secrecy, including without limitation its rights 
pursuant to 37 C.F.R. § 1.14. 

FIELD OF THE INVENTION 

The present invention relates to replication of data stored 
according to a file system format in a computer disk 
partition, and more particularly to a partition manipulation 
architecture that supports different file systems by providing 
interfaces between a file-system-independent replicator and 
one or more file-system-dependent modules. 

TECHNICAL BACKGROUND OF THE 
INVENTION 

The Technical Backgrounds of the parent applications are 
incorporated herein by reference. For convenience, portions 
of the parent applications are also reproduced below. 

Computers utilize a wide variety of disks as storage media 
for user data. Disk technologies currently provide optical 
disks, magnetic disks, hard disks, floppy disks, and remov- 
able disks, and new disk technologies are being actively 
researched and developed. Indeed, some disks used by 
computers in the future may be cubical or some other shape 
rather than flat and circular. 

FIG. 1 illustrates a disk 10 attached to a disk drive 12. The 
disk 10 illustrates physical characteristics of both floppies 
and hard disks; cubical disks or other disks may appear in 
different configurations than the one shown here. The disk 
10 contains a number of concentric data cylinders such as 
the cylinder 14. The cylinder 14 contains several data 
sectors, including sectors 16 and 18. The sectors 16 and 18 
are located on an upper side 20 of the disk 10; additional 
sectors may be located on a lower side 22 of the disk 10. The 
sides 20, 22 of the disk 10 define a platter 24. A hard disk 
may contain several platters. The upper side 20 of the disk 
10 is accessed by a head 26 mounted on an arm 28 secured 
to the drive 12. Optical or cubical disks may be accessed by 
other means, such as photoemitters or photoreceptors. 

A given sector on the disk 10 may be identified by 
specifying a head, a cylinder, and a sector within the 
cylinder. A triplet specifying the head number, cylinder 
number, and sector number in this manner is known as a 
"physical sector address." Alternatively, a given sector may 
be identified by a logical sector address, which is a single 
number rather than a triplet of numbers. 

Many disks mold the available space into one or more 
partitions by using a partition table located on the disk. A 
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wide variety of partitions are used, and more partition types 

will no doubt be defined over time. A partial list of current 

partitions and their associated file systems is given below; 

the trademarks listed are the property of their respective 
5 owners. This list illustrates the benefit of being able to 

manipulate a variety of partitions; it does not follow that 

each and every partition listed should or must be supported 

in a commercial product or in an embodiment of the inven- 
tion described and claimed hereafter: 
10 12-bit FAT 

16-bit FAT>=32 MB, Ext INT 13 

16-bit FAT, partition<32 MB 

16-bit FAT, partition>=32 MB 

32-bit FAT 
15 32-bit FAT, Ext INT 13 

Advanced UNIX 

AIX (Linux) 

AIX Bootable (Linux) 

AIX bootable partition 
20 AIX data partition 

Amoeba bad block table 

Amoeba file system 

AST Windows swap file 

BSDI file system or secondary swap 
25 BSDI swap partition or secondary file system 

Coherent file system 

Coherent swap partition 

Commodore DOS 

Compaq diagnostics 
30 Concurrent CP/M, Concurrent DOS 

CP/M 

CP/M 86 

CTOS (Convergent Technologies OS) 
Cymix 

35 Dell partition spanning multiple drives (array) 

Disabled NT FAT volume set (Q114841) 

Disabled NT IFS volume set (Q114841) (HPFS) 

DiskSecure Multi-Boot 

DOS 3.3+ second partition 
40 DOS access (Linux) 

DR-DOS 6.0 LOGIN.EXE-se cured 12-bit FAT partition 

DR-DOS 6.0 LOGIN.EXE-secured 16-bit FAT partition 

DR-DOS 6.0 LOGIN.EXE-secured Huge partition 

Extended partition or Extended volume 
45 Extended partition, Ext INT 13 

EZ-Drive 3.05 

FreeBSD/386 

GNU HURD 

GoldenBow VFeature 
50 Hidden 12-bit FAT 

Hidden 16-bit FAT>=32 MB, Ext INT 13 

Hidden 16-bit FAT, partition<32 MB 

Hidden 16-bit FAT, partition>=32 MB 

Hidden 32-bit FAT 
55 Hidden 32-bit FAT, Ext INT 13 

Hidden IFS 

Installable file system: HPFS, NTFS 
LANstep 

Linux native file system (ext2fs/xiafs) 
60 Linux Swap partition 

Linux/Minix vl.4b+ 

Mach, MtXinu BSD 4.3 on Mach 

Microport System V/386 

Minix vl. 1-1 .4a 
65 Mitac Advanced Disk Manager 

Mylex DCE376 EISA SCSI controller, past 1024th cyl 

NEC MS-DOS 3.x 
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NexlStep Partition 

Novell Netware 

Novell Netware (3.11 and 4.1) 

Novell Netware 286 

Novell Netware 386 5 

NT FAT volume set (Q114841) 

NT IFS volume set (QU4841) (HPFS) 

Old MINIX (Linux) 

Ontrack Disk Manager 6.0 (DDO) 

Ontrack Disk Manager, read/write 10 

Ontrack Disk Manager, read-only 

Ontrack Disk Manager, write-only 

OPUS 

OS/2 

OS/2 Boot Manager 15 

OS/2 hiding type 04h partition 

PC/IX 

Personal RISC Boot 
Priam EDISK 
Prime 
QNX 

Save to Disk Partition 
Secure File System 
SpeedStor 

SpeedStor 12-bit FAT extended partition 
SpeedStor 16 -bit FAT extended partition 
SpeedStor Dimensions 
SpeedStor Storage Dimensions 
SplitDrive 
Syrinx 

UNIX SysV/386, 386/ix 
VENIX 80286. 
XENIX /usr file system 
Xenix bad-block table 
XENIX root file system 

One partition table composition, denoted herein as the 
"IBM-compatible" partition table, is found on the disks used 
in many IBM® personal computers and IBM-compatible 
computers (IBM is a registered trademark of International 
Business Machines Corporation). IBM-compatible partition 
tables may be used on a wide variety of disks, with a variety 
of partition and file system types, in a variety of ways. 

As shown in FIG. 2, an IBM-compatible partition table 32 
includes an Initial Program Loader ("IPL") identifier 34, 
four primary partition identifiers 36, and a boot identifier 38. 
As shown in FIG. 3, each partition identifier 36 includes a 
boot indicator 40 to indicate whether the partition in ques- 
tion is bootable. At most one of the partitions in the set of 
partitions defined by the partition table 32 is bootable at any 
given time. 

Each partition identifier 36 also includes a starting address 
42, which is the physical sector address of the first sector in 
the partition in question, and an ending address 44, which is 
the physical sector address of the last sector in the partition. 
A sector count 46 holds the total number of disk sectors in 
the partition. A boot sector address 48 holds the logical 
sector address corresponding to the physical starting address 
42. 

Some IBM-compatible computer systems allow "logical 
partitions" as well as the primary partitions just described. 60 
All logical partitions are contained within one primary 
partition; a primary partition which contains logical parti- 
tions is also known as an "extended partition." 

Each partition identifier 36 also includes a system indi- 
cator 50. The system indicator 50 identifies the type of file 65 
system contained in the partition, which in turn defines the 
physical arrangement of data that is stored in the partition on 
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the disk 10 (FIG. 1). Values not recognized by a particular 
operating system are treated as designating an unknown file 
system. The file system associated with a specific partition 
of the disk 10 (FIG. 1) determines the format in which data 
is stored in the partition, namely, the physical arrangement 
of user data and of file system structures in the portion of the 
disk 10 that is delimited by the starting address 42 and the 
ending address 44 of the partition in question. At any given 
time, each partition thus contains at most one type of file 
system. 

An operating system manages access, not only to the disk 
10, but to other computer resources as well. Resources 
typically managed by the operating system include one or 
more disks and disk drives, memory (RAM and/or ROM), 
microprocessors, processors, and I/O devices such as a 
keyboard, mouse, screen, printer, tape drive, modem, serial 
port, parallel port, or network port. 

It is sometimes desirable to alter the contents of an 
IBM-compatible partition table. For instance, a person using 
a computer may wish to move or copy a partition to a 
different location on the disk while substantially or exactly 
preserving the number of disk sectors allocated to the 
partition. 

One conventional approach to modification of an IBM- 
compatible partition table begins by copying all necessary 
user and system data off the disk to a temporary storage 
location such as a tape or another disk. The data copied 
includes without limitation the contents of files created by 
the user such as textual documents and spreadsheets, the 
contents of files required to run applications such as word 
processors, and system data such as directory information. 
Some internal file system data such as sector allocation maps 
does not necessarily need to be copied, but is often copied 
anyway. The familiar disk utility FDISK is then used to 
update the IBM-compatible partition table. The newly speci- 
fied partition is then formatted with the familiar disk utility 
FORMAT or a similar utility (destroying the data on the 
disk). Finally, the data is copied back into the new partition 
on the disk. During this copying process the file system copy 
utility creates appropriate new file system structures reflect- 
ing the current locations of data on the disk. 

This approach to partition manipulation has several draw- 
backs. A temporary storage device with adequate storage 
capacity may not be readily available or affordable under the 
circumstances. Even if temporary storage is available, copy- 
ing large amounts of data from the disk to temporary storage 
and then back again can take a substantial period of time. 

In addition, manipulating IBM-compatible partition 
tables in this manner is confusing and dangerous for many 
computer users. The FDISK utility assumes that the user is 
familiar with the intricacies of IBM-compatible partition 
tables, physical disk addresses, logical partitions, extended 
partitions, operating system assumptions regarding 
partitions, and related matters. Users who are unfamiliar 
with these technical details may easily and inadvertently 
destroy data. 

Less grievous but nonetheless undesirable situations can 
also arise if the user miscalculates the correct size or position 
of the new partitions. For instance, if the partition has been 
made too small to receive all the data from temporary 
storage, it becomes necessary to once again modify the 
partition table with FDISK, to reformat again, and to once 
again copy all the data from temporary storage into the 
reformatted partition. Even if everything works as desired 
the first time, this approach to partition modification can be 
very time-consuming. With a typical disk holding several 
hundred megabytes of data the process may require several 
hours to complete successfully. 
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Some tools, such as those described in the parent 
applications, do allow users who are unfamiliar with tech- 
nical intricacies to manipulate IBM-compatible disk parti- 
tions more easily than is possible with FDISK. However, the 
software architecture implemented by previous tools does 
not cleanly separate file -system -independent components 
from file-system-dependent components. As a result, the 
architecture design makes it difficult to "plug in" modules 
which support additional file systems or modules which 
make better use of knowledge about the internal file-system- 
dependent structure of a partition, such as the file system 
structures that track bad sectors. 

Determining where to draw the line that separates file- 
system-independent components from file-system- 
dependent components is not trivial. It is true that relatively 
few partition manipulations are generally needed; the main 
ones sought are move, copy, shrink, expand, and cluster 
resize. 

However, these manipulations often involve subtleties 
that arise from overlapping partitions, file system 
requirements, bad sectors, error handling, physical disk 
configurations, data structure limitations, or other factors. In 
addition, a wide variety of file systems using very different 
system structures is possible. As a result, there are many 
places where a line separating file-system-independent com- 
ponents from file-system -dependent components might be 
drawn, with varying degrees of success. The implications of 
choosing a particular line of separation may also be hard to 
determine without extensive insight and experimentation. 

Thus, it would be an advancement in the art to provide a 
system which implements a software architecture that 
cleanly separates file-system-independent components from - 
file-system-dependent components. 

It would be an additional advancement to provide such a 
system which reflects knowledge of subtle factors that can 
change the efficiency, correctness, or safety of partition 
manipulations. 

Such a system is disclosed and claimed herein. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides methods and systems for 
implementing partition manipulation tools. One embodi- 
ment of a partition manipulation system implements an 
architecture that supports multiple file systems on a com- 
puter. The computer has a partitionable storage medium for 
holding data in sectors according to a partition table. 

The computer system includes a data replicator for rep- 
licating data from source sectors in a selected partition to 
destination sectors in a modified partition in the partitionable 
storage medium. The data replicator has an initialization 
interface for interfacing to an initialization module. The 
initialization interface has a generic format that is substan- 
tially independent of each file system used on the computer 
system. One embodiment of the initialization interface 
includes a source sector identification, such as a sector or 
cluster bitmap or runmap, that identifies the source sectors; 
a destination sector identification that identifies the destina- 
tion sectors; a bad sector identification; and a result gener- 
ated in response to events such as success, memory alloca- 
tion errors, disk access errors, and requests for replication 
that would place file system or other critical structures in bad 
sectors. 

The computer accordingly also includes at least one 
initialization module. The initialization module(s) may be 
specific to one or more file systems, or they may be default 
modules which are file-system -independent. The initializa- 
tion module(s) generate source sector identifications and 
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otherwise interface with the data replicator through the 
initialization interface. One default initialization module 
requests "dumb" replication by identifying all sectors in the 
selected partition. Some file-system-specific initialization 
5 modules request "smart" replication which avoids bad sec- 
tors. 

A partition table utilizer in the system provides access to 
the partition table to maintain the integrity and self- 
consistency of the partition table during and/or after data 
10 replication. 

The data replicator also has a verification interface for 
interfacing to verification modules; the verification interface 
has a generic format that is substantially independent of the 
file system. The system accordingly includes at least one 
15 verification module which is specific to the file system, for 
verifying the integrity and self -consistency of system struc- 
tures used by the file system, and for interfacing with the 
data replicator through the verification interface. 

The data replicator also has a completion interface for 
interfacing to completion modules according to a generic, 
file-system-independent format. The system includes at least 
one completion module which is specific to the file system 
for updating system structures used by the file system to 
avoid bad sectors. 

25 

In operation, partitions may be copied and/or moved, 
within a disk, .or between disks. The data replicator uses a 
memory buffer to temporarily store data during replication. 
However, a copy of every sector in the selected partition is 
3Q preferably maintained in at least one sector on the disk at all 
times to avoid loss of user data in case replication is 
interrupted by the user, by a power failure, or for some other 
reason. 

Other features and advantages of the present invention 
35 will become more fully apparent through the following 
description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

To illustrate the manner in which the advantages and 
40 features of the invention are obtained, a more particular 
description of the invention will be given with reference to 
the attached drawings. These drawings only illustrate 
selected aspects of the invention and thus do not limit the 
invention's scope. In the drawings: 
45 FIG. 1 is a partial cut-away view of a computer disk. 
FIG. 2 is a diagram illustrating an IBM-compatible par- 
tition table. 

FIG. 3 is a diagram further illustrating a portion of the 
partition table shown in FIG. 2. 
50 FIG. 4 is a diagram illustrating a system which imple- 
ments an architecture of the present invention. 

FIG. 5 is a diagram further illustrating an initialization 
interface shown in FIG. 4. 
55 FIG. 6 is a diagram illustrating a bitmap embodiment of 
a source sector identification shown in FIG. 5. 

FIG. 7 is a diagram illustrating a runmap embodiment of 
the source sector identification shown in FIG. 5. 
FIG. 8 is a diagram illustrating a partition manipulation 
60 which moves a partition to the right to a location that 
overlaps its original location. 

FIG. 9 is a diagram illustrating a partition manipulation 
which moves a partition to the left to a location that overlaps 
its original location. 
65 FIG. 10 is a diagram illustrating a partition manipulation 
which moves a partition to a location that does not overlap 
its original location. 
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FIG. 11 is a diagram illustrating a partition manipulation tic constraints to maintain the integrity self-consistency of 

which copies a partition to a location that does not overlap the data stored in the partition table 32. 

its original location. The partition table utilizer 70 may be embodied in soft- 
ware which runs on the computer 62 and which reflects the 

DETAILED DESCRIPTION OF THE 5 semantic constraints imposed on partitions. Perhaps the 

PREFERRED EMBODIMENTS simplest such constraint is that no sector belongs to two 

The summary and detailed descriptions of the inventions oon-extended primary partitions. Other semantic constraints 

of the parent applications are incorporated herein by refer- 00 P artltl0ns are also well-known. The partition table 32 and 

ence. For convenience, portions of the parent applications f n executable copy of the partition table utilizer 70 will 

are also reproduced below. 10 * f red <?? ° ne of *e disk drives 12 in the 

. . partitionable storage 68, but are shown separately for clarity 

Ine present invention relates to a system for implement- 0 f illustration 

ing a partition manipulation architecture capable of support- ^ system 60 also includes a data repIicator 7Z ^ data 

ing multiple file systems on a computer. One such system 60 replicator 72 is capable of replicating data from a source 

is illustrated m FIG. 4. The system 60 includes at least one sect0 r (such as sector 16 or 18 in FIG. 1) in a selected 

computer 62 which has a processor 64 for executing 15 partition to a destination sector in a modified partition in the 

instructions, a memory 66 for storing instructions, and a partitionable storage medium 68. Like the partition table 

partitionable storage medium 68 for holding data in sectors utilizer 70i the data replicator 72 may include software and 

according to the partition table 32 (FIG. 2). The partitionable an executable copy of the software may be stored on one of 

storage medium 68 includes one or more non-volatile stor- t he disk drives 12 in the partitionable storage 68. 

age devices such as magnetic or optical disk drives 12. The ™ Strictly speakingj there ^ nQ modified tition ^ the 

memory 66 and the partitionable storage medium 68 can be part i tion tab l e 32 (FIG. 2) is updated, even if all the disk 

written and read by execution of appropriate processor 64 sectors that ^ lie m the modified partition haye ^ 

instructions. updated to contain appropriate file system structures and 

Each computer 62 may be a server connected by network user data, because partitions are defined by entries in the 

signal lines to one or more network clients, or it may be a partition table 32. However, for convenience the term 

network client, or it may be a standalone machine. A server "modified partition" means "intended or actual modified 

computer 62 may be configured as an Internet server, as an partition/' That is, "modified partition" is used to denote 

intranet server, as a name server, or as a combination thereof. both the partition that is produced from the selected partition 

A given computer 62 may also function both as a client and 3o and the collection of disk sectors which that modified 

as a server; this may occur, for instance, on computers 62 partition is intended to occupy. Accordingly, one may speak 

running Microsoft Windows NT software (WINDOWS NT 0 f a modified partition, based on an identified selected 

is a trademark of Microsoft Corporation). The processor 64 partition and an identified operation to be performed on the 

may be a uniprocessor or a multiprocessor. Suitable com- selected partition, even before the partition table 32 is 

puters 62 include, without limitation, personal computers, updated and even if the replicating operation is stopped 

laptops, and workstations. Although particular individual before the partition table 32 is updated, 

and network computer system 60 components are identified Details rega rding data replicator 72 software are provided 

herein, those of skill m the art will appreciate that the present b elow and elsewhere. Source sector identification is also 

invention also works with a variety of other systems 60. discussed in connection with FIGS. 6 and 7, and selected 

The illustrated embodiment includes two computers 62 4Q partitions and modified partitions are discussed in connec- 

connected by a network, modems, or other familiar means; tion with FIGS. 8 through 11. The term "replicate" is used 

some alternative embodiments include just one computer 62, herein to indicate moving (as in FIGS. 8 through 10) and/or 

while others include more than two computers 62. The copying (as in FIG. 11). 

selected partition and the modified partition discussed herein nc data replicator 72 has an initialization interface 74 for 

may reside on overlapping portions of a single drive 12, on 45 interfacing to one or more initialization modules 76. The 

different portions of a single drive 12, on different drives 12 initialization modules 76 will often be file-system-specific, 

attached to the same computer 62, or on different drives 12 but a file-system-independent initialization module 76 may 

attached to different computers 62. be prov ided as a default for use when no other modules 76 

Replication may proceed direcdy from a source computer are available. In one embodiment, a default initialization 

62 to the ultimate destination computer 62, or replication 50 module is provided as a C++ base class, and simply requests 

may proceed in stages which use network server files as replication of all disk sectors in the partition without 

intermediate storage. A CD-ROM, a removable file storage attempting to determine whether a collision with bad sectors 

device, or another computer- accessible storage medium may in the modified partition can be avoided. If a bad sector is 

also be used as intermediate storage. found, the replication operation is terminated and the par- 

The software which facilitates the replication may be 55 tition tabic 32 is not modified. Other initialization modules 

loaded for execution from a drive 12 on the computer 62 that 76 are file-system-specific and are capable of relocating file 

holds the selected partition, or the software may be loaded system structure and/or user data sectors in the selected 

over a network or other connection from a file server or partition before their replication to avoid a collision with bad 

some other computer 62. sectors in the modified partition. File -system-specific ini- 

The system 60 also includes a partition table utilizer 70 60 tialization modules 76 may be provided in classes which 

which is capable of extracting from the partition table 32 override the default file-system -independent module 76 base 

information such as partition boundaries, partition sizes, class. 

partition types, and whether a partition is bootable. The In one embodiment, the initialization module 76 is 

partition table utilizer 70 is also capable of modifying the invoked through the following C++ class member function 

partition table 32 to reflect changes in such information 65 header embodiment of the initialization interface 74: 

(once the changes are supplied to the utilizer 70), and of virtual PQRET BeginMove( PARTITION_INFO *srcPi, 

performing the modifications subject to locks and/or seman- STATE_MAP *p, BAD_SECT_LIST *bsl, 



11/05/2003, EAST Version: 1.4.1 



5,930,831 

9 10 

PARTITION_INFO *destPi, ULONG Clear the bits representing the old run in the volume 

*ulSectsPerBlock, ULONG *ulTotalBlocks); bitmap, 

where PARTITION_JNFO is described below, STATE_ Else 

MAP is a bitmap or a runmap or some other identification of Locate several runs in blank areas whose sizes total the 

which sectors to replicate from the source (selected) parti- 5 Q f me portion of the run that is in the region of 

tion to the destination (modified) partition, BAD_SECT_ clusters being vacated. 

LIST is a linked list or table or other identification of e ♦ *u u * *■ .u • .u i u * 

, , to * « T« i i • Set the bits for the new areas in the volume bitmap, 

addresses of bad sectors, ulScctsPerBlock corresponds to the r 

indicator 98, and ulTotalBlocks is the total number of file Co P v the data from . the area ma PP ed b V tDe old mn that 
allocation units in the partition. In an alternative 10 are in the area bem & vacated 10 tne new runs - 
embodiment, ulSectsPerBlock and ulTotalBlocks are Calculate the new run map for the file- 
implicit constants rather than parameters. Of course, global If the new run map is too large for the current MFT File 
variables may also be used in some cases to replace param- Record for the file, including all of its extensions 
eters passed on a stack. The initialization interface 74 is If the MFX does not contain any blank entries, 
discussed further below in connection with FIG. 5. is If the MFT has a muhi le of 64 entfic 

For clarity, the system 60 shown contams only one A , t , . . , . , _ , . 

initialization module 76, but other embodiments include 64 clear b,ts t0 the MFT bltma P' 
several initialization modules 76. Additional initialization 

modules 76 either support other file systems, or make better Add 8 blank entries t0 the MFT addin S enough clusters to 

use of knowledge about the file-system -dependent internal 20 lt t0 hold 8 Flle Rec <>rds and formatting the entries as 

structure of a partition. In one embodiment, for instance, one blank entries, 

module 76 supports FAT partitions and replicates around bad ^ nd ^ 

destination sectors, a second module 76 supports fast rep- Format the next available position in the MFT as an 

lication of NTFS partitions but fails when a bad destination extended File Record. 

sector is encountered, and a third module 76 supports a 25 Set the bit in the MFT bitmap for the new File Record, 

slower replication of HPFS partitions which works around If this is the File Record for the MFT itself (File Record 

bad destination sectors. 0), 

More generally, different embodiments of the initialize- Mov ' e the ^ map minus the mns describiDg the fat 16 

tion modules 76 and data replicator 72 follow different File Records fr om the base File Record to the new File 

patterns with regard to bad sectors in the modified partition. 30 Record 
The most powerful embodiments first identify any bad 

sectors in the modified partition. If bad sectors are found, the c i ™ c-i n a ♦ *u 

,~ , . r . , t . . - \ . Move tne entire run map trom the base rue Record to the 

system 60 determines whether the relative positions of bad new Recor( j 

sectors in the modified partition and the relative positions of £ nc j ^ 

file system structure or user data sectors in the selected 35 T , . . „ , , , r 

partition intersect. If the relative positions intersect then a If toe base Fde Record lacks an AITRIBUTE_LIST 

colhsion would occur. That is, an attempt would be made attribute, 

during replication to write a file system structure or user data Create an ATTRIBUTE__LIST attribute- 
sector to a bad sector, posing an unacceptable risk of loss of ^ nd ^ 

user data. The system 60 therefore relocates the selected 40 Store the calculated run map in the File Record. 

partition sectors that would collide, placing them at new Clear the bits representing the old run in the volume 

relative positions so that no collision will occur. File system bitmap. 

integrity and internal consistency must be maintained by End if 

such relocation, so relocation requires use of a file-system- End if 

specific initialization module 76. The data replicator 72 then 45 End if 

performs the requested replication to produce the modified End for 

partition; a file-system-specific completion module 84 may End for 

be used to update the bad sector table in the modified End while 

partition. A second initialization module 76 embodiment, less pow- 

One procedure for relocating data so that only vacant 50 erful than the first but still very useful, identifies bad sectors 

sectors "collide" (vacant sectors are not written) with bad and detects collisions but returns an error message rather 

sectors is described in a parent application for the NTFS file than trying to relocate selected partition sectors to avoid the 

system, and repeated below for convenience. Similar pro- collision. This approach may also use a file-system-specific 

cedures may be used with other file systems: initialization module 76 to avoid reporting a collision when 

While there are set bits in the volume bitmap for the region 55 the bad sector is at a relative location corresponding to a 

of clusters being vacated, selected partition sector that contains neither file system 

For each file in the master file table (AMFT@), structures nor user data. 

For each run of clusters contained in the file being tested, A third approach simply checks for bad sectors and 

If the run being tested is wholly or partly in the region of r ? orL ! an j*™ if an * are /°™ d * A fourth approach, which 

clusters being vacated, 60 ldentlfies bad sectors onl y after attempting to write file 

Tr . . , . . „ . , . system structures or user data during replication, is also 

If there is a blank area in the region of clusters being ibk bm fe M fcrred 

retained the size of the run being tested, Initialization modules 76 may also relocate file system 

Set the bits for the blank area in the volume bitmap. structures or user data to improve the efiBciency of 

Copy the data from the area mapped by the old run to the 6 5 replication, the efficiency of file system use, or both. For 

blank area. instance, the partition may be defragmented, or it may be 

Change the run in the file to point to the new area. aligned with track or cylinder boundaries. 
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The illustrated data replicator 72 also has a verification 
interface 78 for interfacing to one or more verification 
modules 80, and a completion interface 82 for interfacing to 
one or more completion modules 84. The verification mod- 
ules 80 and completion modules 84 may be default modules 
which are file-system-independent, or they may be file- 
system-specific modules, or a mixture of the two types. 
Some embodiments of the system 60 lack one or more of 
these interfaces 74, 78, 82 and accordingly lack the corre- 
sponding modules 76, 80, 84. 

One file-system-independent verification module 80 
always presumes that the file system integrity and internal 
consistency are intact; "verification" always succeeds. File- 
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system-dependent verification modules 80 perform integrity 
checks such as those performed by the familiar CHKDSK 
program. 

In one embodiment, the verification module 80 is invoked 
5 through the following function header embodiment of the 
verification interface 78: 

PQRET Check(PAKTrnON_INFO "pi) 

io where PQRET provides the return values discussed in con- 
nection with FIG. 5, and pi points to a description of the 
partition to verify. One embodiment of a PARTITION^ 
INFO structure is defined as follows: 



typedef struct partition_info_lag 
{ 

struct partition_info_tag *piNxt; // next on this drive 

DISK_INFO Mi; // DISK_INFO for physical drive 

ULONG Flags; // Partition Info Flags ' 

various constants removed from defines to aid formatting 
// Operations allowed on this partition: 



#define 


PI_LABEL 


// 


#defi.ne 


PLCOPY 


// 


#define 


PI_HIDE 


// 


#define 


PI_UNHIDE 


// 


#definc 


PI_BS_RETEST 


// 


#define 


PI_SET_ACT[VE 


// 


#define 


PI _RESIZE_CLUST 


// 


#define 


PI_RESIZE_ROOT 


// 


#define 


PI__FORMAT 


// 


#define 


PI_DELETE 


// 


#define 


PI_CREATE 


// 


#define 


PI_RESIZE 


// 


#deflne 


PI_CONVERT 


// 


#define 


PI_MOVE 


// 


#deflne 


PI_CHECK 


// 


#define 


PI_INFO 


// 


#define 


PI^\LL_OPS 





// Location and size of partition: 

ULONG StartSect; // start sector relative to beg. of disk 

// (disk begins with boot sector, not EPBR) 
ULONG NumSects; // total num of sectors in the partition 

// Variables set by fast chkdsk: 
ULONG UsedSccts; // # of sectors used 

ULONG FreeSects; // # of sectors free 

ULONG ulEstFilesAndDirs; // Estimated number of files & dirs 
Variables for resizing 
// Location of partition table entry. 

ULONG PartitionSect; // partition sector relative to beg. disk 

UCHAR Partition Index; // Index into partition table 

#define NO_PARTmON_TABLE 

// PartTypc is the partition type value stored in the partition 

// table. It may or may not be correct. Examples are listed in the 

// Technical background portion of this patent application. 

UCHAR PartType; // file system type (value from partition table) 

UCHAR FSType; // File System Type 

#define FS_UNKNOWN PART_UNKNOWN 

#define FS_FAT PART_FAT12 

#define FS_XENIX PART_XENIX 

#define FS_FREE // Free space 

#define FS__NTFS // NTFS (may reside in PART„IFS or PART_FAT) 

#define FS__EXTEND PART„EXTEND // THE one Extended Partition 

#define FS_EPBR // EPBR - Don't display this "partition" 

#define FS_HPFS PART_IFS // HPFS 

#define FS_EXT2FS // Linux ext2fs 

#define FS_LINUX // Lininc/Minix (various) Partitions 

#define FS_PQFLEX // PowerQuest Flex Partition Format 

#define FS_NETWARE // Netware Partition 

#define FS_NOFORMAT // Not formatted 

#define FS_HIGHEST_VAL FS_NOFORMAT // highest FS _xxxx value used 
// Identity of the partition: 

char DriveLetter; // Drive Letter assigned to this drive 

#definc PI_NODL // unknown or no drive letter 

ULONG SerialNumber; // Serial Number of the partition or 0 

#define PI_VOL_LEN 16 // Length allowed for the volume label 
char VolLabellPI_VOL_LEN]; // Volume Label 
#define PI_VOL2_LEN // Length allowed for 2nd volume label 
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-continued 
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char acVoILabcl2[PI_VOL2_LEN]: // Alternate Vblume Label 
// Support file systems where logical sector size != 512 bytes: 



USHOKT BytesPerSect: 
USHORT PhySectsPerLog; 
ULONG ulOSHandle; 
ULONG ulXStartSect; 
//buffer 

ULONG ulXNumSects; 
ULONG ulXPartSect; 
UCHAR ucXPartlndex; 
UCHAR ucXParaype; 
UCHAR ucXFSType; 
UCHAR ucPadl; 
} PARTmON„INFO; 



// # of bytes per logical sector 
// # of physical sects per log sect 
// OS Specific Handle to drive 
// starting sector 

// total # of sectors in the partition 
// partition tabic sector 
// Index into partition table 
// partition type (from partition table) 
// File System Type 
// Pad to align on DWORD boundary 



The verification module 80 may be invoked by the data 
replicator 72 to verify that the file system structures in a 
partition are internally consistent. For instance, a FAT veri- 
fication module 80 performs the verification steps carried 
out by the well-known CHKDSK program, but also inter- 20 
faces with the data replicator 72 according to the file- 
system-independent interface 78. In a preferred 
embodiment, the data replicator 72 invokes the verification 
module 80 for the file system of a given partition before 
replicating any data of the partition, and invokes the veri- 25 
fication module 80 again after replicating the data. 

One file-system-independent completion module 84 
always presumes that the modified partition contains no bad 
sectors not already identified (by relative position or 
otherwise) in the bad sector table of the selected partition. 30 
By contrast, some file-system-dependent completion mod- 
ules 84 update the modified partition's bad sector table using 
a bad sector identification 96 (FIG. 5). 

More generally, one file-system-independent completion 
module 84 always presumes that the modified partition file 
system structures do not need to be updated after replication 35 
by the data replicator 72. Conversely, some file-system- 
dependent completion modules 84 update the modified 
partition's boot record, for instance, when the modified 
partition is a FAT, HPFS, or NTFS partition, or update the 
backup boot record of an NTFS partition. File-system- 40 
dependent completion modules 84 are suitable whenever file 
system structures specify the location of a disk sector or of 
a system structure relative to the disk boundary instead of 
specifying a location relative to a partition boundary. A 
file-system -dependent completion module 84 is also suitable 45 
for updating certain operating system structures, such as the 
partition number in a Microsoft Windows registry. 

In one embodiment, the completion module 84 is invoked 
through the following C++ class member function header 
embodiment of the completion interface 82: 50 

virtual PQRET EndMove( PARTITION_INFO *srcPi, 
BAD_SECT_LIST *bsl, PARTITION_INFO 
*destPi, LOGHAND lhDest); 
where BAD_SECT__LIST and PARTITION_INFO are as 
previously described, and LOGHAND is a typedef of 55 
ULONG (the C++ unsigned long variable type) used as a 
handle to a logical disk I/O session, e.g., for locking and 
unlocking the disk to prevent interference by other processes 
if partition replication is interrupted. Locking and unlocking 
may also be performed by the data replicator 72. One 60 
embodiment of the completion module 84 updates the file 
system's bad sector table and unlocks the partition. Partition 
locking and unlocking may be accomplished by use of a 
recovery partition indicator as disclosed in the parent appli- 
cations. 65 

One embodiment of the initialization interface 74 is 
illustrated in FIG. 5; reference is also made to FIG. 4. The 



interface 74 includes a source sector identification 90 which 
identifies the source sector or sectors to be replicated by the 
data replicator 72. The source sector identification 90 is 
provided to the data replicator 72 to specify which sectors of 
the selected partition should be replicated to produce the 
modified partition. Source sector identifications 90 are dis- 
cussed further in connection with FIGS. 6 and 7. 

The interface 74 may include a destination sector identi- 
fication 92 identifying the destination sector or sectors for 
the replication. In one embodiment, the destination sector 
identification 92 is provided to the data replicator 72 through 
a user interface such as a graphical user interface (GUI) 
described in the parent applications. In one embodiment the 
data replicator 72 sends the destination sector identification 
92 to the initialization module 76 so that the initialization 
module 76 can check the modified partition for bad sectors, 
and (in some cases) relocate user data and/or file system 
structures in the selected partition to avoid collisions with 
bad sectors. 

The destination sector identification 92 may include the 
address of the first sector in a destination location or the 
address of the last sector, as well as an indication of whether 
replication proceeds up (sometimes called "right") or down 
("left") from the address provided. The number of sectors to 
replicate may also be provided. 

A result 94 may be set by the initialization module 76. 
Typical result 94 values include "success", "memory allo- 
cation failed", and "disk error." Other results passed through 
the initialization interface 74 may include "operation can- 
celed by user", "could not lock partition", "unexpected 
internal error", "requested replication not allowed", and 
identification of other unusual or error conditions. 

A requested replication may be disallowed by the initial- 
ization module 76, for instance, if it would place the boot 
sector on a bad sector. More generally, requested replica- 
tions should be disallowed if they would place file system 
structures or user data on bad sectors. A file-system-specific 
initialization module 76 may contain software to relocate file 
system structures or user data sectors to avoid such place- 
ment. 

The verification interface 78 and the completion interface 
82 likewise contain a result field. Verification module 80 
result values may include those already listed for the ini- 
tialization result 94, as well as a variety of file-system - 
specific error indications such as those provided by Scan- 
Disk or CHKDSK. Completion module 84 result values may 
include "success", "disk error", "operation canceled by 
user", "could not unlock partition", "unexpected internal 
error", and values identifying other conditions. 

The embodiment of the initialization interface 74 shown 
in FIG. 5 also includes a bad sector identification 96. This 
may be implemented as a list or table of known or suspected 
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bad disk sectors. Bad sectors may be identified by reading 
bad sector tables maintained by file systems, operating 
systems, or disk controllers, or the list may be generated by 
flushing the disk cache and then attempting to read from the 
disk drive 12 (FIG. 1). 

The bad sector identification 96 may be generated by the 
data replicator 72 and/or by the initialization module(s) 76. 
The identification 96 may be used solely internally by the 
component which generates it, or it may be transferred 
between the data replicator 72 and the initialization module 
(s) 76, for use by the other component or for use by both 
components. The bad sector identification 96 may identify 
bad sectors in the selected partition, in the modified 
partition, or in both partitions. 

The illustrated embodiment of the initialization interface 
74 also includes an indication 98 of the number of sectors in 
a file system allocation unit used by the file system to which 
a given initialization module 76 is tailored. Familiar file 
system allocation units include individual sectors and 
so-called "clusters" of sectors. 

Other embodiments of the initialization interface 74 
include other components, such as a version number, a file 
system identifier, and an indication of whether the initial- 
ization module 76 in question is "smart" in that it works 
around bad disk sectors. 

Alternative embodiments of the source sector identifica- 
tion 90 are illustrated in FIGS. 6 and 7. The embodiment in 
FIG. 6 includes a bitmap 100 containing one bitflag 102 for 
each sector in the source partition. The bitflag 102 corre- 
sponding to a given sector is set if that sector is to be 
replicated, and clear otherwise. The embodiment in FIG. 7 
includes a runmap 104 containing a starting sector address 
106 and a sector count 108 for each run of sectors in the 
source partition which is to be replicated. A run starts at the 
indicated starting address 106 and includes the indicated 
number 108 of contiguous sectors. A file allocation unit may 
be an individual sector or a cluster of contiguous sectors. A 
variation on these embodiments uses bitflags 102 and 
{address 106, count 108} pairs that refer to clusters or other 
file allocation units rather than individual sectors. 

Operation of the data replicator 72 and other components 
of the system 60 is further illustrated in FIGS. 8 through 11; 
reference is also made to FIG. 4. As noted, the modules 76, 
80, 84 provide services to the data replicator 72 through the 
interfaces 74, 78, 82. In one embodiment, an initialization 
module 76 provides the data replicator 72 with the identity 
of the source sectors which are to be replicated and a list of 
any known bad sectors in the destination. The data replicator 
72 obtains the destination from the user through a GUI and 
replicates the indicated source sectors to the specified des- 
tination using a window sizer 86 and a sector replicator 88 
as explained below. After replication, the data replicator 72 
passes the completion module 84 any further information 
obtained about bad sectors during the replication, and the 
completion module 84 updates the file system structures in 
the replicated partition. 

The system 60 allows users to replicate a selected parti- 
tion 110, thereby creating a modified partition 112. As 
illustrated in FIGS. 8 through 10, replication may create the 
modified partition 112 by moving the selected partition 110 
from a source location to a destination location in the 
partitionable storage 68. The source and destination loca- 
tions may be on the same disk drive 12 or on different disk 
drives 12, on the same or different computers 62. 

The source location, shown in the upper portion of each 
of FIGS. 8 through 11, may or may not overlap the desti- 
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nation location, shown in the lower portion of the Figures. 
In the replication examples of FIGS. 8 and 9, a non-empty 
overlap 114 exists, while in the examples of FIGS. 10 and 
11, the overlap 114 is empty. Regardless of whether the 

5 source and destination locations overlap, the selected parti- 
tion 110 is removed from the source destination as a result 
of the moves shown in FIGS. 8 through 10, and left intact as 
a result of the copy shown in FIG. 11. 

10 The overlap 114 influences the size of a "window/* which 
is a group of sectors buffered together in volatile memory to 
be replicated, because it is preferable to avoid overwriting 
the selected partition 110 until absolutely necessary. This 
goal follows from the goal of always maintaining on disk at 

25 least one copy of each data sector used by the selected 
partition, to avoid losing data if the replication is interrupted. 
As explained below, making the window too large increases 
the risk these goals will not be met. 
In theory, replication could proceed through the sectors of 

20 the selected partition 110 in any order However, it is 
convenient for replication to begin with one or more sectors 
located at one end of the selected partition 110 and proceed 
until reaching the last sector at the opposite end of the 
selected partition 110. For purposes of illustration, assume 

25 that replication begins with the left-most sector; the methods 
discussed are readily applied by those of skill in the art if the 
order of replication is reversed or otherwise altered. 

Consider the situation shown in FIG. 8. Suppose the 
leftmost sector of the selected partition 110 is replicated to 

30 its new position at the leftmost location in the modified 
partition 112. Then a sector within the selected partition will 
be overwritten and its contents will be lost (or will be 
susceptible to loss if previously stored only in volatile 
memory), because the overlap 114 is not empty and the 

35 overlapped portion of the selected partition 110 has not been 
saved elsewhere on disk. 

One solution is to replicate from right to left instead of 
from left to right. Another solution is to save the overlapped 
portion of the selected partition 110 elsewhere on disk 

40 before overwriting that portion. These approaches may be 
combined with defragmenting and other compression meth- 
ods which reduce the size of the user data portion of the 
selected partition 110 and thus reduce the portion of the 
overlap 114 that actually poses a problem. 

As a precaution, one embodiment of the invention limits 
the window size to make it no larger than the size of the 
portion of the modified partition 112 that lies outside the 
overlap 114, as shown in FIG. 9. This ensures that sectors of 

50 the selected partition 110 are not overwritten until necessary, 
thereby reducing the risk of data loss. A similar constraint 
can be enforced when replicating from right to left in a 
situation like that shown in FIG. 8. The window size may be 
as large as the entire selected partition 110 if the overlap is 

55 empty, such as in FIG. 10. Some embodiments also reduce 
the window size to increase the frequency of GUI updates 
which inform users as the replication progresses. 

As illustrated in FIG. 11, replication may also create the 
modified partition 112 by copying the selected partition 110 

60 from a source location to a destination location. After a copy, 
the selected partition 110 still exists at the source 
destination, so the source location and destination location 
must not overlap. 
With reference to FIG. 4, in one embodiment the data 

65 replicator 72 includes software described by the following 
C++ code and pseudocode: 
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PQRET pqMove( // Move a partition 

PARTITION_INFO +pi, // Partition to act upon 

ULONG ulStartSect, // New starting sector 

ULONG ulOpFlags) 

( 

MOVE_INFO mi; // Move boundaries 

ULONG ulLimit; // Limit of movement 

PQRET pqRet; // return value 

PQRET pqRet2; // 2nd return value 

LOGHAND lh; // Open a handle to pi 

ULONG ulQuarantine «= LL_QUARANTINED; // {assume the worst) 

COM P LE T I ON_S T AT E eUpdateParts = COMPLETE; // do with afterwards 

SaveState( pi ); // Save off sorae state information 

enGetMovelnf o ( pi, &mi ); // get move bounds 

if (ulStartSect == pi->StartSect ) // if no movement 

( 

no_change: 

return ERRJJO_CHANGE; 

I 

else if (ulStartSect < pi->StartSect ) // if moving down/left 
{ 

// can't start after here 

ulLimit = pi->StartSect - mi . ulFreeBef ore; 

ulStartSect = pqRoundPos { // round to cylinder boundary 

pi->SectsFirstCylinder, //# sects first cylinder 
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pi->SectsPerCylincer, /./# sects all other cyls 
ulStartSect, // Number to round, in sectors 

RS_D0WN ); // Round down if moving down 

while (ulStartSect < ulLimit) // While too low 
5 { 

ulStartSect +« pi->SectsPerCylinder ; // Move up 
if (ulStartSect >= pi->StartSect ) // no change 
{ 

goto no change ; 

10 } 
} 

> 

else // moving up/right 
{ 

15 ulLimit = pi->StartSect * mi. ulFreeAf ter; 

ulStartSect = pqRoundPos { 

pi->SectsFirstCylinder, 
pi->SectsPer Cylinder, 
ulStartSect, 
20 RS_UP ) ; 

while (ulStartSect > ulLimit) // While too high 
( 

ulStartSect -= pi->SectsPerCyl inder ; // Move down 
if (ulStartSect <= pi->StartSect } // no change 
25 goto no_change; 

) 

Check to see if moving above bootable limit 
(1024th cylinder) 
} // end else moving up 
30 Adjust ulStartSect if there is not room to move it where 

specified, but remember Extended is handled differently. 
Open the partition and lock it for exclusive access. 
// Move the partition 

if (pi->FSType == FS EXTEND) // if extended oartition 

35 { 

pqRet = MoveExtended* pi, ulStartSect, ME_SHOW_PROGRESS ); 
ulQuarantine = LL_SAFE_AFTER; // don't quarantine any drives 

) 

else if (pi->Flags & PI_EXTEND) // if logical 

4° pqRet * MoveLogical ( pi, ulStartSect, &eUpdateParts, 

ulOpFlags) ; 

else // if primary 

pqRet - MovePrimary( pi, ulStartSect, SeUpdateParts, 

ulOpFlags) ; 

45 

If the operation wasn't done, do recovery and error handling, 

else // the operation was successful 

I 

if {pi->FSType == FS_N0 FORMAT) //if NOT formatted 

50 pqRet = UpdateUnformatted (pi) ; // Update partition type 

Adjust system structures for new starting sector 

} 

Unlock and close the partition, 
return pqRet; 
55 ) // end pqMove ( ) 

static PQRET MoveExtended ( 

PARTITION_INFO 'piExtend, // Partition to act upon 

ULONG ulStartSect, // New starting sector 

ULONG ulFlags) // MoveExtended flags 

60 ' 
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PQRET pqRet = PQ_OK; // return status 

PQRET pqRet2; // errors during cleanup 

PARTITION_INFO *piTemp; // temporary pointer 

int iNeedPi-0; // flag - need to create pi for 1st EPBR 

5 ULONG ulEndSect; // ending sector of extended (plus one) 

ULONG ulHasFree; // Does the chain have free blocks? 

Check the bounds and make sure the move is legal . 
for example, does it totally delete rhe extended partition? 
10 ulFlags = ulFlags; 

ulHasFree = piExtend->di->Flags & DI_HASFREE; // free blocks? 
Update the chain used internally tc represent partitions. 
// calculate last sector 

ulEndSect =- piExtend->StartSect + piExtend->NurnSects; 
15 Write pqflex sector 

Change file system type to PQFLEX 
Update internal representations of partitions. 
Change MBR for new size. 
Update all EPBR's for the new base. 
20 Restore partition type. 

If necessary create a PI structure for the 1st EPBR. 
Handle any errors, 
return pqRet; 
) // end MoveExtendedO 
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// Assume: ulStartSect is different than pi->StartSect . 
// Assume: All partitions end on a cylinder boundary. 



static PQRET MoveLogicaK // Move a logical drive 

30 PARTITION_INFO *pi, // Partition to act upon 

ULONG ulStartSect, // New starting sector 

COMPLET I ON_STATE *peUpdateParts, // do afterwards 
ULONG ulOpFlags) 

\ 

35 PQRET pqRet = PQ_0K; 

PARTI TION_INFO 'piClone =* NULL; // for higher StartSect 

ULONG ulEncloseSize; // Size necessary to enclose old & new 
ULONG ul01dStartSect=pi->StartSect; // Old starting sector 
ULONG ulEpbrSect; // EPBR will be moved to here 

40 PARTITION INFO *piExtend; // The extended oartition 

PARTITION_INFO *piTmp; // Misc, temporary pi pointer 

PQRET pqRet2; // 2nd return value 

PQRET pqWarn =» PQ_OK; 
PQRET pqWarn2; 

ULONG ulFlags=OL; // Keep track of recovery procedures necessary: 
const ULONG RESTORE_TYPE = Restore original partition type 
const ULONG RESTORE_POS = Restore original partition position 

const ULONG RESTORE_SIZE = Restore original partition size 
const ULONG RESTORE_l ST_FREE - 
50 Restore PI for EPBR for free space at start of extended 

const ULONG RESTORE PI^POS = Restore pi->StartSect , pi->NumSects 

Check the bounds and make sure the move is legal. 
Run a Check before the move. 
55 T est ulEpbrSect and make sure the sector is not bad. 

Hake a copy of the pi structure. 

Change partition to enclose both old and new positions. 
Then move the data. 

If move forces resize left boundary of extended partition, 
60 do so . 

If beyond extended boundary 
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Move start of extended. (This must be done before 
MoveLogical writes its PQFLEX sector, because 
MoveExtended will write a PQFLEX sector of its own, 
5 possibly overwriting MoveLogica.l ' s . ) 

pqRet « MoveExtended (piExtend, ulEpbrSect, 0) ; 
if {pqRet) 

goto Exit; 

} 

10 If free space at start of extended is totally consumed, 

delete the pi. 
Write PQFLEX sector. 

From this point on, we need to roll back or complete the 
partition table changes. 
15 MoveVolume < ) will change the value as appropriate. 

Change file system type to PQFLEX. 

Update the partition tables to enclose old & new areas. 

pqRet = pqMoveParti.tion(pi,ulStartSect, ulEncloseSize) ; 

If an error occurs, it means we orobably can't update the 
20 EPBR : By virtue of RESTOR£_POS, we'll attempt to restore the 

partition table chain the way it was. 

At this point, pi/piClone are set up as follows: 

pi points to the lower address, the destination, and its 

NumSects encloses both areas. 
25 piClone points to the higher address, the source, and has 

the old NumSects. 

// Move the data over 

pqRet = MoveVolumeCpi, piClone, peUpdateParts, uIOpFlags); 
If failure, if we're supposed to roll back, Assume that no 
30 writes were made anywhere by MoveVolume ("} . If this is not 

the case, we will have to restore the original EPBR and 
possibly an EPBR for free space at the start of the extended 
partition . 

If FAIL_UNSTABLE don't bother restoring position. 
Go ahead and restore the partition type - maybe CHKDSK can 
salvage something. At very least, FDISK can delete it. 
Update EPBR with logical's true size and position. 
Change the partition table. 
If an error occurs, we're in big trouble. 
Change the File System back to its true type. 
Check the integrity of the file system. 
If errors made it necessary, undo some of the changes. 
If we allocated a copy of pi deallocate it. 
return pqRet ? pqRet : pqWarn; 
45 ) // end MoveLogical ( ) 

static PQRET MovePrimary ( 

PARTITION_INFO *pi, // Partition to act upon 

ULONG ulStartSect, // New starting sector 

50 // What do we do with partition afterwards 

COMPLETION_STATE *oeUpdateParts, 
ULONG uIOpFlags) 

PQRET pqRet = PQ_0K; 

55 PARTITION_INFO *piH.igh » NULL;// clone of pi for higher StartSect 

ULONG ulFlags=0L; // Flags for error recovery 

ftdefine MP_RESTORE_FREE 0x00000001 // Need to restore free blocks 
PQRET pqRet2; // 2nd return value 

PARTITION_INF0 'piTemp; // return value from pqFindPart 

60 PROGRESS 'progress = NULL; 
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NEW (progress, PROGRESS); 

progress->SetRange (0, 4); // Set progress range for ore-check 

error->Begin?reCheck ( ) ; 
5 pqRet = Check {pi ) ; 

IF^PQRET; // Run a Check before the move 

progress->SetRange{5, 95); // Set progress range for move 

10 Check the bounds and make sure the move is legal. 

//If error now, don't do anything special to partitions 
*peUpdateParts=COMPLETE; 

15 // partition is moving over free space in extended partition? 

piTemp = pqFindPart ( // Find a partition/sector intersection 

pi->di->piExtend, // Start looking with this partition 
ulStartSect, // start of sector range 

20 ulStartSect + pi->NuraSects - 1, // end of range 

FP_EXTEND ); // Does pi and extended intersect? 

Tf it overlaps, resize the extended partition, as necessary. 
pqRet = pqClonePi (pi, &piHigh) ; 
25 if fpqRet) 

return pqRet; 
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vRemoveFreef pi->di ); // remove free blocks from this chain 
ulFlags |= MP_RESTORE_FREE; // We'll need to restore them later 

Write PQFLEX sector. 

// From this point on, we need to roll back or complete the 
// partition table changes. 

// MoveVolumeO will change the value as appropriate. 
*peUpdate Parts - FAIL_ROLLBACK; 

Change file system type to PQFLEX. 
IF_PQRET; 

40 

// Change partition to enclose both old and new Dositions. 
// Then move the data. 

if (ulStartSect < pi->St artSect ) // if moving lower 

45 pqRet = pqUpdatePt{ // Update the partition table entry 

pi, // partition to update 
ulStartSect,// new value of 1st sector 
pi->StartSect + pi->NumSects );// same end 

IF PQRET; 

50 

piTemp = pi; 

pqRet = MoveVolume( // move the data over 

pi, //to this partition 
piHigh, // from this partition 

// What do we do with the partition after moving the data 

peUpdateParts, ulOpFlags} ; 
I F_ PQRET; 

f 

else //if moving higher 
60 { 

pqRet = pqUpdatePt( // Update the partition table entry 
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piHigh, // partition to update 

pi->StartSect, // start remains same 
ulStartSect + pi->NumSects ); // new end 

IF_PQRET; 

5 // Changing PARTITION_T NFO members outside pqiib.cpp 

// can have unexpected side effects. 
// For DOS and OS/2, we change StartSect and 
// NumSects and clean up later: 
// let the low pi enclose entire space 
10 pi->NumSect3 = piHigh->NumSects ; 

piHigh->StartSect - ulStartSect; 
piHigh->NumSects ~ pi->ulXNumSects; 

// Move the data over 
15 piTemp = piHigh; 

pqRet = MoveVolume( // move the data over 

piHigh, // to this partition 

pi, // from this partition 

peUpdateParts, ulOpFlags) ; 

20 I F_PQRET; 

} 

// At this point, pi/piHigh are set up as follows: 
//pi points to the lowest address and its NumSects encloses both 
25 // areas 

// piHigh points to the highest address and has the old NumSects 
// Update MBR to final size. 

// (assumed that if pqRet == 0, then ^peUpdateParts »- COMPLETED.) 

30 Update the partition table entry. 

Change the File System back to its true type. 
Run a Check after the move. 

Exit : 

delete progress; 
35 if £*peUpdate?arts == FAIL_ROLLBACK) 

// if we need to change back oartition 
{ 

pqRet2 = pqUpdaceP- { // Update the partition table entry 
pi, // partition to update 
pi->ulXStartSect, // old value 1st sector 
pi->ulXStartSect + pi->ulXNumSect s }; 
// old value of last sector + 1 
if (! pqRet) // if no previous error 

pqRet = pqRet2; // remember this one 
45 pqRet2 = pqChangePartType { // to original file system 

pi# // change this partition 

pi->ucXPartType, // orig partition type 
pi->ucXFSType > ; // orig file system type 
if (IpqRet) // if no previous error 

50 pqRet = pqRet 2; // remember this one 

i 

if (piHigh) // if we allocated a copy of pi 

pqFreeClonel fipiHigh ); // deallocate it 
if (ulFlags & MP_RESTORE_FREE) // If we need to restore free blocks 



40 



55 { 



pqRet2 = pqAddFree( pi->di ); 
// add free blocks back to this chain 

if (! pqRet) // if no previous error 

pqRet = pqRet 2; // remember this one 



60 } 

return pqRet; 
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} // end MovePrimary ( ) 



// Does not require move/copy to be on same drive 

// File system specific tasks are handled by callouts through 

// virtual functions. 

// One embodiment of the sector replicator 68 includes MoveVolume ( ) . 
PQRET MoveVolumei 

PARTITION_INFO *piDest, // pointer to destination partition 
PART IT TON_ INFO *piSrc, // pointer to source partition 
C0MPLETION_STA?E 'estate, // reports completion stare 



ULONG ulFlags, 
ULONG ultfoveCopy) 



// 
// 



bad sector flags 
are we called from move or 



copy 



20 



25 



30 



40 



45 



50 



55 



60 



PQRET pqRet = 0; 

VOLUMEBASE *pVol = NULL; // 
STATE_MAP *pBitMap = NULL; // 
PROGRESS ^progress = NULL; // 
PROGRESS 'moveProgress = NULL;// 



pointer hides file system 
bitmap for moving blocks 
dummy progress 
move progress 



BAD_SECT_LIST *bsl = NULL; // bad sector list new location 
□CHAR *pucReadWriteBuf = NULL;// buffer for block reads and writes 

// position next read/write in buff 



move flags 

size in sectors of each block 
size in bytes of each block 
total # of blocks in partition 
# blocks in read/write buffer 
begin block of operation 
// beg'g bitmap pos'n read/write operations 
// end bitmap position for read/write operations 
// # of blocks in current read/write operation 



// 
// 
// 
// 
// 
// 



// 
// 
// 

// total 
;// current 
// returns 
DONE } 



UCHAR *pucReadWri.tePos 
ULONG ulMoveFlags = 0 
ULONG ulSectsPerBlock 
ULONG ulBytesPerBlock 
ULONG ulTotalBlocks; 
ULONG ulTotalBIocksInBuf fer; 
ULONG ulCurWindow; 
ULONG ulBeginRun; 
ULONG ulEndRun; 
ULONG ulRunSize; 
ULONG ulLoop; 
ULONG ulNewStart; 
ULONG ulNewEnd; 
ULONG ulBlocksToMove; 
ULONG ulMoveSects; 
ULONG ulCurMoveSect = 
ULONG ulBlocksLeft; 
enum { READ_PASS, WRITE_PASS, 
LOGHAND lhDest-PQILLHAND; 
LOGHAND lhSrc=PQILLHAND 
*e3tate = FAIL_ROLLBACK 
NEW (progress , PROGRESS } 
pqRet = pqLogOpen( 

piDest, 
&lhDest) ; 

I F_PQRET; 

pqRet = pqLogOpen{ 

piSrc, 
&lhSrc) ; 

I F_PQRET; 

pqRet = MountVolume ( 

piSrc, 

sulMoveFlags 
// allow MountVolume to flag the volume DUMB 
&pVol ) ; 

// returns pointer to specific volume, masks it in a VOLUME BASE 
I F_PQRET; 

// references to pVol are restricted to base class references 

ulNewStart ~ piDest->StartSect ; 

// find new area and direction of the move 

ulNewEnd = piDest->StartSect + piSrc->ulXNumSects - 1; 



target start physical sector 
target end physical sector 
returns # of blocks in window 
ove operations (for progress) 
tt move ops (for progress) 
# of blocks found in window 
pass; 

// Destination handle 

// Source handle 

// setup for any failure 



// Open the destination partition 
// The destination partition 
// Returns handle here. 



// 
// 
// 



Open the source partition 
The source partition 
Returns handle here. 



// mount (and init) the volume 
// pointer to the source partition 
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if i-jlMoveCopy & M0VE_COPY) 

// if we're doing a copy (behaves same as move down) 

ulMoveFiags 1= MOVE_DOWN; 
ulMoveFiags &= -MOVE OVERLAPS ; 

} 

else if {piDest->StartSect < piSrc->StartSect ) 

t //if moving down 

UlMoveFiags != MOVE_DOWN; 

if ( {ulNewStart + piSrc->ulXNumSects) > piSrc->StartSect ) 
UlMoveFiags |= KOVE_OVERLAPS ; 
| e ^ se // if moving up 

ulMoveFiags j - M0VE_UP; 

if (piSrc->StartSect + piSrc->ulXNumSects > ulNewStart) 

{ 

ulMoveFiags |= MOVE OVERLAPS; 

} 

} 

if (piSrc->FSType == FS_ NO FORMAT ) // setup progress variable 

ulMoveSects - 2; 
// count once for sects read, once for sects written 
else if (ulMoveFiags & MOV E_ DUMB) 

ulMoveSects = piSrc->ulXNumSects * 2; 

else 

ulMoveSects = piSrc->UsedSects * 2; 
NEW(bsl, BAD_SECT_LIST) ; 

if ( (ulFlags 6 PREF_BS_TEST) II (ulMoveFiags & MOVE_DUMB) ) 
Do bad sector test 

If NOT formatted, test boot sector only. 

If it's a dumb move (doesn't work around bad sectors) 

and bad sector test is off, we will test anyway. 

If it's a dumb move quit testing after 1 found, otherwise 

find all bad sectors. 

// set the progress (report to user thru GUI ) range for move 
progress->SetRange( { ulTestSects* 100) / 
iTestSects+ulMoveSects) , 10C); 
> 

NEW (pBi tMap, STATE_MAP) ;// bitmap for moving blocks (1 bit/block) 
pqRet ~ pVol->BeginMove (// file system specific initialization 
pBitMap, 

// on return, bitmap contains used blocks (none bad) 
bsl, 
piDest , 

SulSectsPerBlock, 
// returns size (in sectors) of each block 

AulTotalBlocks) ; 
// returns number of blocks in volume 
I F_ PQRET; 

// derive block variables 

ulBytesPerBlock = ulSectsPerBlock * piSrc->BytesPerSect ; 
ulTotalBlocksInBuffer - // determine how much memory to allocate 

pqQueryCoreOpt () ; 
ulTotalBlocksInBuffer /= // do allocation in blocks 

ulBytesPerBlock; 
if { ! ulTotalBlocksInBuffer) // not enough memory for 1 block 

pqRet - ERR_0EjT_MEM0RY ; 
goto Exit; 

> 
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if (uITotalBlocksInBuf fer > ulTotalBlocks) 
uITotalBlocksInBuf f er = 

// limit move by total blocks in partition 
ulTotalBlocks; 

5 if { (ulMoveFlag3 & MOVE_UP) && (ulMoveFlags & MOVE_OVERLAPS) ) 

{ 

uITotalBlocksInBuf f er - 

// Limit moves up by move distance of move 

min(ulTotalBlocksInBuf fer, (ulNewStart - piSrc- 
10 >StartSect> / ulSectsPerBlock) ; 
} 

NEW{pucReadWriteBuf , UCHAR ( uITotalBlocksInBuf fer * 
ulBytesFerBlockj ) ; 

NEW (rnoveProgress , PROGRESS (GP_AL LOW CANCEL) ) ; 
15 if {ulMoveCopy & MOVE_COPY) // set progress text to MOVE I I COPY 

moveProgress->SetText ( PROG_CO? Y I NG_DATA } ; 

else 

mcveProgress->SetText (PROG_MOVING_DATA) ; 
fcdefine MAX_RUN_SIZE 5000// limit to allow progress to update nicely 
20 ulEndRun = 0;// init start bit for (move down or non-overlapped) 

ulCurWindow = ulTotalBlocks; 

// initialize start bit for (overlapped move up) 

while (1) // move until we've determined there is no more 

{ 

25 ulCurWindow = GetNextWindow ( 

// returns position of next read/write window 

ulCurWindow, // position of last window processed 
ulMoveFlags, // which direction to move window 
pBitMap, // pointer to the bitmap 

30 ulTotalBlocks, // don't go beyond end of partition 

uITotalBlocksInBuf fer, 

// window size limited by read/write buffer 
ulEndRun, 

// start bit for (move down or non-overlapped) 
35 &ulBlocksToMove) ; 

// returns number of blocks found in window 
if (ulBlocksToMove 0) // quit if no more 

break; 

■W // scan bitmap once, fill read buffer, scan again and write 

#pragma warning 139 10 // turn off ++enum warning 

for (pass = READ_PASS; pass !» DONE; pass++) 
ftpragma warning 139 1 // turn on + + enum warning 

{ 

45 ulEndRun = ulCurWindow; 

pucReadWritePos = pucReadWriteBuf ; 
ulBlocksLeft = ulBlocksToMove; 
while (ulBlocksLeft) 

// while window not completely processed 
50 { 

// scan the bitmap for the first block with data 
ulBeginRun - p3itMap->GetNextSet (ulEndRun) ; 
// determine consecutive blocks 
ulEndRun = pBitMap->GetNextClear (ulBeginRun) ; 
55 // if consecutive blocks go beyond partition 

if ((ulEndRun == -1) || {ulEndRun > 

ulTotalBlocks]) 

ulEndRun = ulTotalBlocks; 
// if consecutive blocks won't fit in buffer 
60 if (ulEndRun - ulBeginRun > ulBlocksLeft) 

ulEndRun = ulBeginRun + ulBlocksLeft; 
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25 



40 



45 



50 



// may have to pare down the ulRunSize here if it is too large 
//' for 'progress' to update nicely 

if (ulEndRun - ulBeginRun > MAX_RUN_SIZE) 

ulEndRun = ulBeginRun + MAX_RUN_SIZE; 

// calculate the run size 

ulRunSize = ulEndRun - ulBeginRun; 

// update progress 

ulCurMoveSect += ulRunSize - ulSectsPerBlock; 
pqRet = moveProgress->Update (ulCurMoveSect , 

ulMoveSects) ; 

// if a CANCEL occurs and we are allowing it.., 
if (pqRet £& *eState != COMPLETE) 
goto Exit; 

if [pass == READ_PASS } // pass == READ_PASS 

if (*eState = COMPLETE) 
//if failure would be catastrophic, ignore disk errors 
( 

ForceRead { 

lhSrc, // partition 

(void * JpucReadWritePos, // buffer 

ulBeginRun * ulSectsPerBlock, 

// begin sector 

ulRunSize * ulSectsPerBlock, 

// number of sectors to read 

piSrc->BytesPerSect) ; 

} 

else 

// else quit if read fails 
i 

pqRet = pqLogRead( 

/ / read logical sectors 

lhSrc,// partition to read 

ulBeginRun * ulSectsPerBlock, 

/ / begin sector 

{void *)pucReadWritePos, 

// sector buffer 

ulRunSize * ulSectsPerBlock); 

// number of sectors to read 

I F_ PQRET; 

} 

} 

else // pass =- WRITE PASS 



// if (user cancel OK) 



if ((*eState != COMPLETE) 



(ulMove Flags f. MOVE_OVERLAPS ) && 
( ( (ulMoveFlags & MOVE_DOWN) && 
// and move down will overwrite the source 

(piSrc->StartSect <= piDest- 
>StartSect + ulEndRun * ulSectsPerBlock}) || 

, , ((ulMoveFlags & MOVE UP) && 

// or move up will overwrite the source 

« - «-n - ^ . (piSrc->StartSect + piSrc->ulXNumSects 

55 s> piDest->StartSect + ulBeginRun - ulSectsPerBlock)))) 

( 

pqRet = moveProgress- 

>DisableCancel ( } ; 

I F_PQRET ; 

"estate = COMPLETE; 
// flag user cancel 'not OK' 
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} 

if {* estate =- COMPLETE) 
//if failure would be catastrophic, ignore 
\ 

ForceWrite( 

IhDest, 



(void *) pucReadWritePos, 
ulBeginRun * UlSectsPerBlock, 
ulRunSize + ulSectsPerBlock, 
10 piSrc->BytesPerSect } ; 

} 

else 

// else quit if write fails 

15 pqRet = pqLogWrite( 

// write logical sectors 
IhDest, 

ulBeginRun * ulSectsPerBlock, 
(void *) pucReadWritePos, 
ulRunSize * ulSectsPerBlock); 
IF_PQRET; 

} 

} 

ulBlocksLeft -= ulRunSize; 
** 5 // done processing this run 

pucReadWritePos += ulRunSize * ulSectsPerBlock * 

piSrc->BytesPerSect ; 

} 

30 } 

// file system specific cleanup 

pqRet .= pVol->EndMove(bsl, piDest, IhDest); 

I F_ PQRET; 

pqRet = pVol->UpdateHiddenSects (piDest, piSrc->FSTvpe IhDest)* 
35 Ir_PQRET; • 

*eState = COMPLETE; 
pqRet = moveProgress->Done () ; 
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if (MOVE_DUMB tpiSrc->DriveLetter != PI NODL) ) 
pqSe; Reboot Flag( ) ; 



Exit : 



if (IhDest !- PQILLHAND) // if handle was opened 

pqLogClose( IhDest ); // -lose it 

45 if < lhSrc ! = PQILLHAND) // if nandle was opened 

pqLogClcse( IhSrc ); // close it 

delete pBitMap; 

delete bsl; 

delete pVol; 
50 delete moveProgress; 

// delete progress objects in reverse order of creation 

delete progress; 

delete pucReadWriteBuf ; 

return pqRet ; 
55 ) // end MoveVolume ( ) 

// The window is determined from the bitmap and is limited by the 
// number of blocks in the read/write buffer. 

// One embodiment: of the window sizer 86 includes GetNextWindow ( ) . 
60 static ULONG GetNextWindow ( // returns first block in window 
ULONG ulLastWindow, // start of last window 
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ULONG ulMoveFlags, // which direction to move window 

STATE_MAP *pBitMap, // pointer to the bitmap 

ULONG ulTotalBlocks, // don't go beyond end of partition 
ULONG ulBlocksInBuf f er , // window limited by read/write buffer 
5 ULONG ulStart 

// start bit for (move down or non-overlapped) 

ULONG *ul3locksToMove) // returns # of blocks found in window 

i 

ULONG ulNextWindow; 
10 ULONG ulEndWindow; 

// if moving down (same as moving to a new drive} or no overlap 
if ((ulMoveFlags 6 HOVE_DOWN) I I ! (ulMoveFlags & MOVEJDVERLAPS) ) 

f 

ulNextWindow - // start at the next used cluster 
15 pBitMap->GetNextSet (ulStart) ; 

// if there is no next used cluster 

if [ (ulNextWindow == (ULONG)-l) I I (ulNextWindow >= 

ulTotai31ocks) ) 

20 *ulBlocksToMove = 0; 

return 0; // we are done 

} 

ulEndWindow = ulTotalBlocks-1 ; 

// go until end of partition (or buffer full) 

25 } 

else 
( 

ulEndWindow - 

// end at the used cluster immediately previous to last window 
30 pBitMap->GetPrevSet {ulLastWindow} ; 

if (ulEndWindow == (ULONG) -1) 

{ // if there is no previous used cluster 

*ulBlocksToMove =0; //we are done 
return 0; 

35 } 

else if (ulEndWindow < ulBlocksInEuf f er ) 
{ 

ulNextWindow = 0; // start at beginning of partition 

} 

-10 else 

{ // start at the move_up fixed limit 

ulNextWindow = ulEndWindow - ulBlocksInEuf f er + 1; 

1 

} 

45 *ulBlocksToKove = 

pBitMap->GetSetCount ( 

ulNextWindow, // start counting at ulNextWindow 
ulEndWindow,// count through' ulEndWindow- 1 
ulBlocksInBuf fer) ; 

50 // don't count more than will fit in buffer 

return ulNextWindow; // return first block in window 
' // end GetNextWindow ( ) 

// MountVolume ( ) Returns initialized pointer to a volume class, 
55 // disguised as a BASE_VOLUME * 
static PQRET MountVolumet 

PARTI TION_INFO *p, 

ULONG ^ulMoveFlags, 

VOLUM£_BASE **pVol) 

60 { 

PQRET pqRet - 0; 
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if (p->?SType =- FS_NOFORMAT) // if UNFORMATTED 

{ 

NEW{ *pVol, VOLUME_BASE(p) ) ; 

) 

else if (p->FSType — FS_FAT) // if FAT (SMART ) 

{ 

NSW ( *pVol, FA T_ VOLUME (p) ] ; 

} 

else if (p->FSType == FS_NTFS) //if NTFS (SEMI_SMART) 

i 

NEW(*pVol, NTFS_VOLUME(p) } ; 



else // else UNKNOWN 

{ 

15 NEW(*pVol, VOLUME_BASE(p) ) ; 

// this will only happen if check lets 
*ulMoveFlags 1= MOVE_DUMB; 

// unknown partitions through (i.e., HPFS, LINUX) 

} 

20 // Initialize the Volume 

pqRet = (*pVol)->Init(J; 

Exit: 

if (pqRet) 
{ 

q 25 delete (*pVol> ; 

^ return pqRet; 

p3 ) // end MountVoluraeO 

>£T 30 static void SaveState( // Save away some state information 
h PARTITION_INFO *pi )// Partition to act upon 

pi->ulXStartSect = pi->StartSect; // starting sector 
pi->ulXNumSects = pi->NumSects; 
35 // total number of sectors in the partition 

0 pi->ulXPartSect * pi->PartitionSect; // partition table sector 
J£ pi->ucXPartIndex = pi->PartitionIndex; 

I / Index into partition table 

1 . pi->ucXPartType = pi->PartType; 

? „ 40 // partition type (value from partition table) 

''U pi->ucXFSType = pi->FSType; // File System Type 

vj return; 

} // end SaveStateO 
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In summary, the present invention provides a novel sys- an initialization module which is capable of generating 

tern and method for implementing partition manipulation the sector identifications and otherwise interfacing with 

tools. Generic interfaces allow the use of a single data the data replicator through the initialization interface; 

replicator 72 with multiple filc-system-specific modules 76, and 

80, 84. This makes it possible to decrease costs, improve 5 a partition table utilizer for accessing the partition table 

reliability, broaden applicability and otherwise enhance par- and maintaining the integrity and self-consistency of 

tition manipulation tools, including tools for moving and/or the partition table in connection with data replication, 

copying partitions, while supporting efficient, correct, and 2. The system of claim 1, wherein the data replicator, 

safe partition manipulations. initialization module, and partition table utilizer in combi- 

Articles of manufacture within the scope of the present 10 nation provide a means for copying a partition to a different 

invention include a computer-readable storage medium in location on the partitionable storage medium, 

combination with the specific physical configuration of a 3. The system of claim 1, wherein the data replicator, 

substrate of the computer-readable storage medium. The initialization module, and partition table utilizer in combi- 

substrate configuration represents data and instructions nation provide a means for moving a partition to a different 

which cause the computers to operate in a specific and ^ location on the partitionable storage medium, 

predefined manner as described herein. Suitable storage 4. The system of claim 1, wherein the data replicator, 

devices include floppy disks, hard disks, tape, CD-ROMs, initialization module, and partition table utilizer in combi- 

RAM, and other media readable by one or more of the nat i on pr0 vide a means for replicating a partition from one 

computers. Each such medium tangibly embodies a pro- disk to another disk in the partitionable storage medium, 

gram, functions, and/or instructions that are executable by 2Q 5. The system of claim 1, wherein the initialization 

the machines to perform partition tool implementation steps interface source sector identification includes a file alloca- 

and/or provide separation between file -system-dependent tion unit bitmap. 

and file-system-independent components of a partition 6. The system of claim 1, wherein the initialization 

manipulation tool substantially as described herein. interface source sector identification includes a file alloca- 

Although particular methods embodying the present 25 tion unit runmap. 

invention are expressly illustrated and described herein, it 7. The system of claim 1, wherein the initialization 

will be appreciated that apparatus and article embodiments interface source sector identification identifies all sectors in 

may be formed according to methods of the present inven- the selected partition. 

tion. Unless otherwise expressly indicated, the description 8. The system of claim 1, wherein the initialization 

herein of methods of the present invention therefore extends 30 interface further includes an indication of the number of 

to corresponding apparatus and articles, and the description sectors in a file system allocation unit used by the initial- 

of apparatus and articles of the present invention extends ization module file system. 

likewise to corresponding methods. Unless otherwise stated, 9. A computer system implementing a partition manipu- 
any list of included items is exemplary, not exclusive of lation architecture capable of supporting multiple file sys- 
other items; "includes" means "comprises" not "consists 35 terns on a computer, the computer having a processor for 
of." executing instructions, a memory for storing instructions, 
The invention may be embodied in other specific forms and a partitionable storage medium for holding data in 
without departing from its essential characteristics. The sectors according to a partition table, the memory and the 
described embodiments are to be considered in all respects partitionable storage medium being accessible by execution 
only as illustrative and not restrictive. Any explanations 40 of processor instructions, the computer system comprising: 
provided herein of the scientific principles employed in the a data replicator for replicating data from a source sector 
present invention are illustrative only. The scope of the in a selected partition to a destination sector in a 
invention is, therefore, indicated by the appended claims modified partition in the partitionable storage medium, 
rather than by the foregoing description. All changes which the data replicator having an initialization interface for 
come within the meaning and range of equivalency of the 45 interfacing to any of a plurality of initialization mod- 
claims are to be embraced within their scope. ules according to a format which is substantially inde- 
What is claimed and desired to be secured by patent is: pendent of each file system of the computer system, the 
1. A computer system implementing a partition manipu- initialization interface including a source sector iden- 
lation architecture capable of supporting multiple file sys- tification identifying the source sector; 
tems on a computer, the computer having a processor for 50 an initialization module which is capable of generating 
executing instructions, a memory for storing instructions, the sector identifications and otherwise interfacing with 
and a partitionable storage medium for holding data in the data replicator through the initialization interface; 
sectors according to a partition table, the memory and the and 

partitionable storage medium being accessible by execution a partition table utilizer for accessing the partition table 

of processor instructions, the computer system comprising: 55 and maintaining the integrity and self-consistency of 

a data replicator for replicating data from a source sector the partition table in connection with data replication; 

in a selected partition to a destination sector in a wherein the initialization module avoids bad sectors by 

modified partition in the partitionable storage medium, omitting sectors from at least one of the initialization 

the data replicator having an initialization interface for interface sector identifications. 

interfacing to any of a plurality of initialization mod- 60 10. A computer system implementing a partition manipu- 

ules according to a format which is substantially inde- lation architecture capable of supporting multiple file sys- 

pendentof each file system of the computer system, the tems on a computer, the computer having a processor for 

initialization interface including a source sector iden- executing instructions, a memory for storing instructions, 

tification identifying the source sector, the initialization and a partitionable storage medium for holding data in 

interface further including a result generated in 65 sectors according to a partition table, the memory and the 

response to events which include success, memory partitionable storage medium being accessible by execution 

allocation errors, and disk access errors; of processor instructions, the computer system comprising: 
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a data replicator for replicating data from a source sector 
in a selected partition to a destination sector in a 
modified partition in the partitionable storage medium, 
the data replicator having an initialization interface for 
interfacing to any of a plurality of initialization mod- 
ules according to a format which is substantially inde- 
pendent of each file system of the computer system, the 
initialization interface including a source sector iden- 
tification identifying the source sector; 

an initialization module which is capable of generating 
the sector identifications and otherwise interfacing with 
the data replicator through the initialization interface; 
and 

a partition table utilizer for accessing the partition table 
and maintaining the integrity and self-consistency of 
the partition table in connection with data replication; 

wherein the initialization interface further includes a bad 

sector identification. 

11. A computer system implementing a partition manipu- 
lation architecture capable of supporting multiple file sys- 
tems on a computer, the computer having a processor for 
executing instructions, a memory for storing instructions, 
and a partitionable storage medium for holding data in 
sectors according to a partition table, the memory and the 
partitionable storage medium being accessible by execution 
of processor instructions, the computer system comprising: 

a data replicator for replicating data from a source sector 
in a selected partition to a destination sector in a 
modified partition in the partitionable storage medium, 
the data replicator having an initialization interface for 
interfacing to any of a plurality of initialization mod- 
ules according to a format which is substantially inde- 
pendent of each file system of the computer system, the 
initialization interface including a source sector iden- 
tification identifying the source sector; 

an initialization module which is capable of generating 
the sector identifications and otherwise interfacing with 
the data replicator through the initialization interface; 
and 

a partition table utilizer for accessing the partition table 
and maintaining the integrity and self-consistency of 
the partition table in connection with data replication; 
wherein the initialization module is specific to at least one 
file system of the computer system and includes a means for 
relocating user data to avoid colliding with a bad sector 
during replication, 

12. A computer system implementing a partition manipu- 
lation architecture capable of supporting multiple file sys- 
tems on a computer, the computer having a processor for 
executing instructions, a memory for storing instructions, 
and a partitionable storage medium for holding data in 
sectors according to a partition table, the memory and the 
partitionable storage medium being accessible by execution 
of processor instructions, the computer system comprising: 

a data replicator for replicating data from a source sector 
in a selected partition to a destination sector in a 
modified partition in the partitionable storage medium, 
the data replicator having an initialization interface for 
interfacing to any of a plurality of initialization mod- 
ules according to a format which is substantially inde- 
pendent of each file system of the computer system, the 
initialization interface including a source sector iden- 
tification identifying the source sector; 

an initialization module which is capable of generating 
the sector identifications and otherwise interfacing with 
the data replicator through the initialization interface; 
and 
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a partition table utilizer for accessing the partition table 
and maintaining the integrity and self -consistency of 
the partition table in connection with data replication; 
wherein the data replicator also has a verification interface 
for interfacing to any of a plurality of verification modules 
according to a format which is substantially independent of 
the file systems, and the system further comprises a verifi- 
cation module which is specific to at least one file system, 
which is capable of verifying the integrity and self- 
consistency of system structures used by the at least one file 
system, and which is capable of interfacing with the data 
replicator through the verification interface. 

13. A computer system implementing a partition manipu- 
lation architecture capable of supporting multiple file sys- 
tems on a computer, the computer having a processor for 
executing instructions, a memory for storing instructions, 
and a partitionable storage medium for holding data in 
sectors according to a partition table, the memory and the 
partitionable storage medium being accessible by execution 
of processor instructions, the computer system comprising: 

a data replicator for replicating data from a source sector 
in a selected partition to a destination sector in a 
modified partition in the partitionable storage medium, 
the data replicator having an initialization interface for 
interfacing to any of a plurality of initialization mod- 
ules according to a format which is substantially inde- 
pendent of each file system of the computer system, the 
initialization interface including a source sector iden- 
tification identifying the source sector; 

an initialization module which is capable of generating 
the sector identifications and otherwise interfacing with 
the data replicator through the initialization interface; 
and 

a partition table utilizer for accessing the partition table 
and maintaining the integrity and self-consistency of 
the partition table in connection with data replication; 
wherein the data replicator also has a completion interface 
for interfacing to any of a plurality of completion modules 
according to a format which is substantially independent of 
the file systems, and the system further comprises a comple- 
tion module which is capable of interfacing with the data 
replicator through the completion interface. 

14. The system of claim 13, wherein the completion 
module is specific to at least one file system of the computer 
system and is capable of updating system structures used by 
the at least one file system to avoid bad sectors. 

15. A computer system implementing a partition manipu- 
lation architecture capable of supporting multiple file sys- 
tems on a computer, the computer having a processor for 
executing instructions, a memory for storing instructions, 
and a partitionable storage medium for holding data in 
sectors according to a partition table, the memory and the 
partitionable storage medium being accessible by execution 
of processor instructions, the computer system comprising: 

a data replicator for replicating data from a source sector 
in a selected partition to a destination sector in a 
modified partition in the partitionable storage medium, 
the data replicator having an initialization interface for 
interfacing to any of a plurality of initialization mod- 
ules according to a format which is substantially inde- 
pendent of each file system of the computer system, the 
initialization interface including a source sector iden- 
tification identifying the source sector; 

an initialization module which is capable of generating 
the sector identifications and otherwise interfacing with 
the data replicator through the initialization interface; 
and 
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a partition table utilizer for accessing the partition table 
and maintaining the integrity and self -consistency of 
the partition table in connection with data replication; 
wherein the data replicator utilizes an area of memory to 
temporarily store data during replication, and the size of the 5 
memory area depends at least on the extent of any overlap 
between the selected partition and the modified partition, the 
amount of available memory, and the size of the selected 
partition. 

16. A computer system comprising: 10 
a computer having a processor, a memory, and a parti- 

tionable storage medium for holding data in sectors 
according to a partition table; 

data replication means for replicating data from source 
sectors in a selected partition to destination sectors in a 15 
modified partition in the partitionable storage medium, 
the data replication means comprising a window sizing 
means for determining the maximum number of sectors 
to be buffered together in volatile memory; 

file-system-specific initialization module means for gen- 20 
erating a source sector identification; and 

initialization interface means for interfacing the data 
replication means with the initialization module means 
in a file-system -independent format. 25 

17. The system of claim 16, further comprising means for 
reading and writing a partition table. 

18. A computer system comprising: 

a computer having a processor, a memory, and a parti- 
tionable storage medium for holding data in sectors 30 
according to a partition table; 

data replication means for replicating data from source 
sectors in a selected partition to destination sectors in a 
modified partition in the partitionable storage medium; 

file-system-specific initialization module means for gen- 35 
erating a source sector identification; 

initialization interface means for interfacing the data 
replication means with the initialization module means 
in a file-system-independent format; 

verification module means for processing a request to 40 
verify the integrity and self-consistency of file system 
structures; and 

verification interface means for interfacing the data rep- 
lication means with the verification module means in a 
file -system-independent format. 45 

19. A computer system comprising: 

a computer having a processor, a memory, and a parti- 
tionable storage medium for holding data in sectors 
according to a partition table; 

data replication means for replicating data from source 
sectors in a selected partition to destination sectors in a 
modified partition in the partitionable storage medium; 

file-system-specific initialization module means for gen- 
erating a source sector identification; 55 

initialization interface means for interfacing the data 
replication means with the initialization module means 
in a file-system-independent format; 

completion module means for processing a request to 
update system structures; and 60 

completion interface means for interfacing the data rep- 
lication means with the completion module means in a 
file-system-independent format. 

20. A computer system comprising: 

a computer having a processor, a memory, and a parti- 65 
tionable storage medium for holding data in sectors 
according to a partition table; 
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data replication means for replicating data from source 
sectors in a selected partition to destination sectors in a 
modified partition in the partitionable storage medium; 

file-system-specific initialization module means for gen- 
erating a source sector identification; 

initialization interface means for interfacing the data 
replication means with the initialization module means 
in a file -system -independent format; and 

a means for identifying bad sectors in the modified 
partition; 

wherein a bad sector is located at a relative position within 
the modified partition, a user data or file system structure 
sector is located at a relative position within the selected 
partition, and the system further comprises a means for 
determining whether the relative position of the bad sector 
and the relative position of the user data or file system 
structure sector intersect. 

21. The system of claim 20, further comprising a means 
for relocating the user data or file system structure sector so 
that the relative position of the bad sector and the relative 
position of the user data or file system structure sector do not 
intersect. 

22. A method for providing a partition manipulation toot, 
comprising the computer-assisted steps of: 

providing a data replicator for replicating data from 
source sectors in a selected partition to destination 
sectors in a modified partition in a partitionable storage 
medium, the data replicator having a window sizer 
which determines the maximum number of sectors to 
be buffered together in volatile memory; 

providing an initialization module for generating a source 
sector identification; and 

interfacing the data replicator with the initialization mod- 
ule in a file-system-independent format. 

23. The method of claim 22, wherein the step of providing 
an initialization module includes providing a file-system - 
specific initialization module. 

24. The method of claim 22, further comprising the 
computer-assisted step of providing means for reading and 
writing a partition table. 

25. The method of claim 22, further comprising the 
computer-assisted step of using the interfaced data replicator 
and initialization module to produce a modified partition by 
replicating a selected partition. 

26. The method of claim 25, wherein the modified parti- 
tion and the selected partition reside on the same disk drive. 

27. The method of claim 25, wherein the modified parti- 
tion and the selected partition reside on different disk drives 
which are attached to the same computer 

28. A method for providing a partition manipulation tool, 
comprising the computer-assisted steps of: 

providing a data replicator for replicating data from 
source sectors in a selected partition to destination 
sectors in a modified partition in a partitionable storage 
medium; 

providing an initialization module for generating a source 
sector identification; 

interfacing the data replicator with the initialization mod- 
ule in a file-system-independent format; 

providing a file-system-specific verification module for 
verifying the integrity and self -consistency of file sys- 
tem structures; and 

interfacing the data replicator with the verification module 
in a file-system-independent format. 

29. A method for providing a partition manipulation tool, 
comprising the computer-assisted steps of: 
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providing a data replicator for replicating data from providing a file -system-specific verification module for 

source sectors in a selected partition to destination verifying the integrity and self-consistency of file sys- 

sectors in a modified partition in a partitionable storage tem structures; and 

medium; interfacing the data replicator with the verification module 

.j. ...... < , f t - 5 in a file-system-independent format. 

providing an initialization module for generating a source ~- ~ * . i • ia u 

■j - fi • 3 5 * The computer storage medium ot claim 34, wherein 

sector identification; the step of providing an initialization module includes 

interfacing the data replicator with the initialization mod- providing a file-system -specific initialization module. 

ule in a file -system-independent format; 36. The computer storage medium of claim 34, wherein 

providing a file-system-specific completion module for 10 £ e * te P of providing a data replicator includes providing a 

updating file system structures used to avoid bad sec- Wl ?_ ow n . SlZer " ,. r . . . 

I . 5 ^ ' • ■^ ne computer storage medium of claim 34, wherein 

' the method further comprises the computer-assisted step of 

interfacing the data replicator with the completion module providing means for reading and writing a partition table. 

in a file-system-independent format. 38. The computer storage medium of claim 34, wherein 

30. A method for providing a partition manipulation tool, 15 the method further comprises the steps of: 

comprising the computer- assisted steps of: providing a file -system -specific completion module for 

providing a data replicator for replicating data from J£?2d ^ SyStCm StrUCtUrCS USed 10 aV ° id bad SCC * 

source sectors in a selected partition to destination , , . , , 

M/1(AW • „ , n „ t - inn •„ „ „^- t - „^ K1 ^ otrt „ M interfacing the data replicator with the completion module 

sectors in a modified partition in a partitionable storage 20 * fl , , J . . r , r 

. r r fe zu in a file-system-independent format. 

1 * 39. The computer storage medium of claim 34, wherein 

providing an initialization module for generating a source the method further comprises the computer-assisted step of 

sector identification; using the interfaced data replicator and initialization module 

interfacing the data replicator with the initialization mod- to P roduce a modified partition by replicating a selected 

ule in a file -system-independent format; 25 pa ^i tl( ^ 4 - . . ~~ 

r 40. The computer storage medium of claim 39, wherein 

using the interfaced data replicator and initialization mod- me modified partition and the selected partition reside on the 

ule to produce a modified partition by replicating a same disk drive. 

selected partition; 41. The computer storage medium of claim 39, wherein 
wherein the modified partition and the selected partition 30 tne modified partition and the selected partition reside on 
reside on different disk drives which are attached to two different disk drives which are attached to the same corn- 
different computers. puter. 

tu *u a -Ft* in xl jt, . . 42. The computer storage medium of claim 39, wherein 

31. Hie method of claim 30, further comprising the me modified aQ( f me ^ ^ oQ 

computer-assisted step ot creating an intermediate tile on a differeQt 6isk drives which 

are attached to two different 

server computer which is connected by a network to the two 35 com p U ters 

different computers. 43 ^ computer storage me dium of claim 42, wherein 

32. The method of claim 30, further comprising the the method further comprises the computer-assisted step of 
computer-assisted step of creating an intermediate file on a creating an intermediate file on a server computer which is 
computer-readable storage medium. ^ connected by a network to the two different computers. 

33. A computer storage medium having a configuration 44. The computer storage medium of claim 42, wherein 
that represents data and instructions which will cause at least the method further comprises the computer-assisted step of 
a portion of a computer system to perform method steps for creating an intermediate file on a computer-readable storage 
providing a partition manipulation tool, the method steps medium. 

comprising: 45 45. A computer storage medium having a configuration 

• j. j , . r , . c that represents data and instructions which will cause at least 

providing a data replicator for replicating data from r . . r iL j . r 

, „ . i.j «. j a portion of a computer system to perform method steps for 

source sectors m a selected partition to destination ... J . . . y , , 

. ~ • — j'c j • ut * providing a partition manipulation tool, the method steps 

sectors in a modified partition in a partitionable storage r . r r r * r 

medium, the data replicator having a window sizer; comprising. 

...... - , r cn providing a data replicator for replicating data from 

providing an initialization module for generating a source 50 _ * „ • 1 * j . j .* *• 

r vi fi ■ a source sectors m a selected partition to destination 

sector identification; and secfc)rs m ft modified partit i on in a partitionable storage 

interfacing the data replicator with the initialization mod- medium; 

ule in a file-system-independent format. providing an initialization module for generating a source 

34. A computer storage medium having a configuration ^ ciox identification- 

that represents data and instructions which will cause at least interfacing thc data replicator ^ the initializal ion mod- 

a portion of a computer system to perform method steps for ^ in a file . system . independent format; 

providing a partition manipulation tool, the method steps c , , .» . . . r 

comnrVnir r providing a file -system-specific completion module for 

updating file system structures used to avoid bad sec- 

providmg a data replicator for replicating data from 6Q tors , and 

source sectors in a selected partition to destination inlerfa ' cing the data replicator ^ the completion module 

sectors id a modified partition in a partitionable storage ^ a B ^ syaem .j otapeakM format. 

me ium ' 46. A computer storage medium having a configuration 

providing an initialization module for generating a source ma t represents data and instructions which will cause at least 

sector identification; 65 a portion of a computer system to perform method steps for 

interfacing the data replicator with the initialization mod- providing a partition manipulation tool, the method steps 

ule in a file -system-independent format; comprising; 
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providing a data replicator for replicating data from 
source sectors in a selected partition to destination 
sectors in a modified partition in a partitionable storage 
medium; 

providing an initialization module for generating a source 
sector identification; 

interfacing the data replicator with the initialization mod- 
ule in a file-system-independent format; and 
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using the interfaced data replicator and initialization mod- 
ule to produce a modified partition by replicating a 
selected partition; 
wherein the modified partition and the selected partition 
reside on different disk drives which are attached to two 
different computers. 
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